Thanks! Why is it better to use let..in here?

It's not necessarily better per se, but variables such as ${out} and friends don't exist until after the derivation is created. This will be useful when we start exposing include paths and so forth.

I think it will also allow us to look at source files after patches are applied, but I haven't tested this yet.

After these formatting changes, I will be able to use said ${out} and similar variables which don't exist before the derivation is complete the grant easy attribute access to include, lib and source paths of the dependencies for usage in other scripts.

Are the changes according to best-practices or a common formatting tool? As these changes are cosmetic, I'd prefer to have a way to enforce/check that we follow the right format in the future (e.g. a linter or formatter). If it's just your preference I suggest we close it for now and make the necessary changes in PRs that require them :-)

I'm not actually sure what best-practices or recommended formatting styles are. I can look into it.

The changes do facilitate the mechanism to export paths as attributes, but there might be better ways to do it: this was just the first approach I thought of that allowed a consistent way of doing that.

Yea, so the guideline should be "Tools Not Rules". So there needs to be a tool, like .editorconfig or clang format that produces these whitespace changes in a way that's consistent for all developers. Then that has to be discussed and agreed on, and then the tool should be applied once to the whole code base to make it conform. When we're convinced that the PR with whitespace changes are just a result of applying the tool we agreed on, accepting the whitespace changes is basically an auto merge.